tests: drivers: spi: extend error_cases test. #97275
Conversation
zephyrbot
added
area: Tests
nordic-babu
force-pushed
the
extend-spi-error-cases
branch
2 times, most recently
from
a13b59a to
0379236
Compare
Extend with no reconfiguration on every tranceive case. Signed-off-by: Bartlomiej Buczek <[email protected]>
nordic-babu
force-pushed
the
extend-spi-error-cases
branch
from
0379236 to
37250eb
Compare
|
Please let me know if it's not enough https://github.com/zephyrproject-rtos/zephyr/blob/main/include/zephyr/drivers/spi.h#L434, If not I will move this to nordic-specific area for now, this scenario just matched exisitng test suite pretty well for me. On the other hand frequency of 124999Hz is afaik not documented as invalid anywhere, but such case is present in already existing tests. |
|
This is a weird case of the API , where the API is not saying how things should be but has a warning about how things may be, so I don't know if it's right to be testing other behavior as an "error". Let's see what @tbursztyka and @teburd think about it |
|
on the plus side: at least we'll notice if this behavior changes during some rework and make sure that such a change is intentional (as it requires change in tests). |
| /* change valid config frequency to invalid value */ | ||
| spim_valid.config.frequency = 124999; | ||
|
|
||
| /* make sure device is not reconfigured because conf structure pointer is the same |
There was a problem hiding this comment.
This doesn't quite look right to me, why would it not be reconfigured here? Each transceive should be viewed as unique, if you go changing the spi bus frequency between transceives this should be valid, not sure why this wouldn't change the frequency. That's highly confusing behavior.
We've gone through this sort of thing before, create the test with the desired/conforming behavior not the existing broken one. |
And this is broken behavior imho |
5 participants
Extend with no reconfiguration on every tranceive case.